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ABSTRACT 


This thesis presents an integer programming model to help the Navy develop 
long-range shipbuilding plans. The model is of a general nature, but is proposed 
specifically as a decision aid for the developers of the Navy’s Extended Planning 
Annex (EPA). The EPA sets forth planned ship purchases five to 20 years in the 
future. It is currently produced with a mainly manual process that takes weeks at a 
time, hence it is extremely difficult for the EPA planners to respond quickly to 
changes in the given data and assumptions. The optimization model suggests 
delivery dates for new ships, based on given budgets and requirements, and 
accounts for such complexities as the extra costs of building a leadship or of 
resuming construction after a production break. The model has been formulated 
with the General Algebraic Modeling System (GAMS) and effectively solved with 
two commercial optimization packages. It performs fast enough to allow the planner 


to make several “what if’ runs in the course of developing the EPA. 
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I. BACKGROUND 


This research is an attempt to assist the Navy in planning ship purchases five to 
20 years in the future. An optimization model is developed which will produce an 
initial ship purchase plan. This proposed plan can then be used as a starting point 


for developing the actual plan set forth in the Extended Planning Annex. 


A. EXTENDED PLANNING ANNEX (EPA) 

The Extended Planning Annex (EPA) is an annex to the Five Year Defense 
Program which shows the planned status of the Navy and Marine Corps assets in 
the years following those covered by the Five Year Defense Program. It is a “best 
guess” of what the Navy will consist of in those years far in the future. It is not an 
approved expenditures list, but a long range plan which can be updated or changed 
as the budget, the current status of the Navy, or its requirements change. The basic 


concept behind the EPA is an affordability analysis of future programs. 


B. HOW THE EPA IS USED 

Many decision makers in the Department of the Navy use the EPA in preparing 
their own long range plans. The EPA shows the projected status of the Navy’s 
ships, aircraft, and personnel based on the Navy’s analysts’ expectation of what will 
be affordable. Many decisions concerning today’s assets invariably depend on what 
kinds of assets are expected to be available in the future. For example, if a new 
carrier is planned in the EPA to come on line in seven years, the personnel who will 
be rotating at that time will have to decide whether they want to serve on that carrier, 
and the detailers will be penciling in people to be the high ranking officers. If the 


new carrier comes on line as scheduled in the EPA the escort ships must be ready to 


proceed with the new carrier when it goes out to sea. Also, an older carrier may be 
sent to the yards for an overhaul based on when the new carrier comes on the line to 


take its place. This is of course only one example, many others could be cited. 


C. HOW THE EPA IS CURRENTLY DEVELOPED 

The current procedure for developing the EPA involves a member of the Chief 
of Naval Operation’s OP-81 staff (currently LCDR M. J. Zurey) spending a great 
amount of time trying to develop a ship purchase schedule which will be affordable 
and maintain desired fleet characteristics. Some of the scheduling is relatively easy 
since the decision is mandated by other documents (e.g., the number of ballistic 
missile submarines is included in treaties). Most decisions have more latitude and are 
made through a manual trial and error process. Many considerations must be taken 
into account, and examples of these include: 

1. When are ships going to be retiring and thus require replacement? 

2. When are ships going to be built to replace retiring ships? 

3. How much money in each year is left over after the required ship purchases? 
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. Is it better to build a new ship or extend the life of the ships coming up on 
retirement through the Ship Life Extension Program? 


5. Is there enough money to build several ships all of which need to be 
delivered in the same year? If not, when should each be built? 


6. Should the production line for one type of ship be stopped in order to 
release funds to build another type ship? 


7. Will there be enough personnel to man the ships which are being built? 


8. Will the budget for ship construction increase or decrease, and by how 
much? 


9. If a ship retires without a replacement, will the Navy be able to meet the 
national force requirements with the remaining ships? 


This is not an exhaustive list of questions and important factors. Fiscal 
considerations are complex. Ships are not paid for when they are delivered, but 
require installments years ahead of delivery, and lead ships do not cost the same as a 
typical ship off the production line. Also, one must remember that allocations of 
millions or billions of dollars are being planned for use five to twenty years in the 
future. The need to satisfy many conditions and to keep track of expenditures for 
several years suggests the use of a computer rather than a manual procedure. The 
need to make good decisions about how to best allocate money suggests the use of 
an optimization or simulation model. Optimization or simulation techniques can then 
be used to assist the decision maker in choosing the best values for the decision 
variables. Reference 1 describes simulation models as “strategy evaluation models” 
and optimization models as “strategy generation models.”’ Thus, in order to use a 
simulation model, every possible combination of purchase plans (or at least every 
sensible plan) must be generated ahead of time. Each plan is evaluated by the model 
and the best plan selected. This is simply not feasible with the number of possible 


alternatives available. This is the reason for choosing an optimization model. 


D. THE NEED FOR A COMPUTER MODEL 

The current long range plan is developed manually by an analyst at OP-81. One 
plan generally requires weeks to prepare. If there is a change either in the budget or 
the threat scenario, the plan must be redeveloped from the beginning. In order to 
reduce the time required to develop long range plans LCDR Zurey requested that 
the Naval Postgraduate School’s Operations Research Department conduct research 
on how to computerize the process. As part of the computerization, a model must 
be developed. The main purpose of this study is the development of an optimization 


model to aid analysts in preparing long range plans. 


II. OPTIMIZATION MODEL 


The model is presented in two versions: conceptual and implementation. The 
conceptual version of the model is designed for ease of presentation, to provide a 
rough idea of the model’s capability before presenting the more complicated version 
that was actually implemented. Both models use “elastic” [Ref. 2] or “soft” [Ref. 3: 
pp. 36-37] constraints and a penalty function associated with the elastic variables as a 
means for finding a highly desirable, if not classically “optimal,” long range plan. 
Elastic variables allow constraints to be violated at a cost. They allow the model to 
reflect the common managerial practice of violating some constraints in order to 
satisfy others or to improve the objective function. To accomplish this, two elastic 
variables are added to each equality constraint, and one elastic variable to each 
inequality constraint. Elastic variables have penalties as their coefficients in the 
objective functions. They are restricted to be nonnegative and will take on positive 
values when the corresponding constraints are violated. One advantage of elastic 
constraints is the ease of obtaining an initial feasible solution to the model. 
Following the notation originated in Brown and Graves [Ref. 2], relational 
operators with a small circle on the top indicate elastic constraints. This notation 
eliminates the need for explicitly displaying the actual elastic variables in the model, 
thereby making it easier to read. (The notation also reflects Brown and Gaves’ 
computional practice in their X-System solver [Ref. 4] of treating elastic variables 


implicitly.) 


A. CONSIDERATIONS 


To be useful, the model must be realistic and flexible. To be flexible, a model 


should allow the user to perform “what if” type of analysis (e.g., ““What happens to 


the plan if the projected budget goes down instead of up?”, or “What happens to the 


plan if we need another carrier?’”’). To be realistic, a model must include the 


following features: 


Ve 


A production line for a ship type may stop and be restarted. This happens 
when funds must be transferred from one ship type to another. In general, 
there is also a cost associated with restarting a production line. 


Allow for bounds on the number of ships being constructed in a given year. 
Each ship type has an upper bound and a lower bound on the number that can 
be constructed per year, if any are constructed. There is also an overall bound 
on the number of ships which may be under construction at any one time. 


Payments for a ship are required long before the ship is delivered. Some ships 
require payments in multiple years prior to delivery. Some ships require 
expenditures after delivery, e.g., for outfitting. Each ship type has its own 
payment schedule. 


Leadships require payment structures that are different from the follow-on 
ships. A leadship costs more and takes longer to build. Additionally, the 
leadship is delivered in a year by itself, with a year (or perhaps two years) 
enforced delay before any more ships of that type are delivered. 


. CONCEPTUAL MODEL 


1. Index Use 


i Ship type { CVSEGN, FFG, 25} 

d Calender year of ship delivery { 1990, 1991, 1992, ... } 

p Calender year of payment { 1990, 1991, 1992, ... } 

k Ship’s production status { typical, resumption, leadship } 


A “resumption” status indicates that this is the first ship of its type to be 


constructed following a break in the production line. All the cost of restarting the 


production line is added to this ship. The “leadship” status is reserved for the very 
first ship of a given type. All other ships are given the status of “typical.” All 


inappropriate index combinations are screened out. 


2. Given Data 
ship quantity data 
need,, | Quantity of ship type / needed in year d. 


have;, Quantity of ship type i that are in year 0 inventory and will still be in 
operation in year d. 


gettingjq Quantity of ship type i that are currently under construction and will 
become available in year d. 


The net demand for ship type i up to year d is derived as follows: 


netdemjd =need,, - have;; - Yeetting,,. 
d’<d 


It should be emphasized that the number of ships needed in future years is an 
input to this model. These needs are determined by other analysts and 
communicated to the OP-81 officer in charge of scheduling the ship purchases. 
jiscal data 

Cikdp Cost in year p for each ship of type i and status k delivered in year d. 

budget, Money available to purchase ships in year p. 

Fiscal data is generally given in units of millions or hundreds of millions 
of constant year dollars. Defining the cost parameter with two time subscripts (d and 
p) allows for greater flexibility in modeling ship costs. For example, if p < d then 
the cost is due to construction, and if p > d then the cost is due to outfitting. The 


actual method for inputting the cost is much easier than filling in the four 


dimensional array Cikdp» 4S shown in the Appendix. 


production limitations data 
lag; Number of years required to construct a ship of type i.. 
upbnd;, Upper bound on quantity of ship type i that can be delivered in year d. 


Iwbnd;, Lower bound on quantity of ship type i that can be delivered in year d 
if any are delivered. 


sybnd, Upper bound on total number of ships that can be under construction 
in year p. 


policy data 
Relative penalties for elastic variables associated with elastic constraints. The 
value assigned to these penalties has a profound influence on the solution. The 
method used in this research is described in Chapter III. 
3. Decision Variables 
The decision variables in the conceptual model are: 
Xikd Number of ships of type i and status k to be delivered in year d. 
Elastic variables associated with elastic constraints also exist, but are not 
explicitly referred to as decision variables. The value of Xjxqg for k = “resumption” 
or ‘“‘leadship’” must be binary, while for k = “typical” it is a general integer. 
4. Formulation 
The conceptual formulation minimizes the total penalty cost associated with 
violation of the elastic constraints to be described below. This type of planning 
usually involves so many conflicting constraints that it is generally impossible to 
satisfy all the constraints inelastically. 
MIN: >) PENALTIES 


ST: 1) DEMANDjg: [Ensure that the number of type i ships 
delivered during or prior to year d meets the net demand.] 
Xikd’ = netdemjd, V id 
a =d k 


2) FISCALp: [Observe budget in year p.] 
Dcikdp Xikd = budgetp, Vp 


3) CONSTRUCT>p: [Observe limit on the number of ships 
under construction in year p.] 
Xikd S sybndy,Vp 
ik Osd-pSlagj 


4) Ensure the total number of ship type i delivered in year d 
is € { 0, lwbndjg, ... , upbndjq }. 


5) For new ship types, force the leadship to be delivered before 
any typical ships. 


6) Force a resumption unit to be delivered following a 
production break. 

The first three sets of constraints are relatively easy to handle. The logical 
constraints (4) - (6) require further development. In particular, constraints (5) and 
(6) involve non-convex costs, and therefore a linear programming optimizer will 
tend to violate them. Constraint (4) requires using general integer decision variables 
with a range of values from a disjoint set of integers (e.g., {0, 3, 4, 5 }). Like the 


non-convex costs, this condition causes computational difficulty in practice. 


C. IMPLEMENTATION MODEL 
1. Decision Variables 
The implemented version of the model uses binary decision variables 
exclusively. This choice is more amenable than general integer variables to most 
solvers and it proves advantageous when constructing logical constraints. 
However, it increases the number of decision variables. The conceptual model uses 
index k to distinguish ship status, “typical”, “resumption”, or “leadship”. The 


implemented version instead uses three separate variables for this purpose. 


Additionally, a new index / is used to indicate the quantity ordered for typical ships. 
The new binary variables and their meaning are: 

XTjgj=1 << j=number of typical ships of type i to be delivered in year d. 

XRjg=1 << A resumption ship of type i is to be delivered in year d. 

XLig=1 © A leadship of type / is to be delivered in year d. 

Since the index k has been dropped, the cost coefficients are similarly 

redefined: 

Clip Cost in year p for each typical ship of type i delivered in year d. 


Tidy Cost in year p for each resumption ship of type i delivered in year d. 
Cli, Cost in year p for each leadship of type i delivered in year d. 
All inappropriate index combinations are screened out prior to sending the 
model to the solver. The binary variables with index / are related to the original 


variables as follows: 
Xid'typical’ = di XTidj 
A binary variable must be defined for each possible positive value of Xjq‘typical’. 
To allow at most one of the new binary variables to take the value of 1 for each pair 
of i and d, the following generalized upper bound (GUB) is added: 
> XTiaj <1, Vid 
J 


Using this construction of binary variables rather than the usual “powers- 
of-two”’ factorization [Ref. 5:p. 190] allows discontinuity to be more easily handled. 
For example, if Xig'typical’ € {0, 3, 4,5 } then XTjqj will be defined only for j = 
3,4, and 5. The other values will be screened out. It easy to see that / could be 
defined for any discrete set, even when several discontinuities exist. Handling this 


with the usual “powers-of-two” factorization would be difficult. The major 


drawback to this method is that it is only practical when the number of possible / 
values is small, otherwise too many binary variables will be introduced. 

In the implementation model, we define XTjqj for j = lwbndjq-1, ... , 
upbndjq. This allows a resumption ship after a production break to be delivered in 
the same year as lwbndjg-1 typical ships. 

2. Formulation 
The three constraints that were expressed mathematically in the conceptual 


model translate directly to the implementation model as follows: 


DEMAND: > [ » J XTid' + XRig’ + ie | = netdemjg, Vid 
d'<d j 

FISCALp: ml yy J XTjgftidp + XRiactidp + XLiaclidp ] = budgetp , V p 
L Ni 


CONSTRUCTp: yy I | OS i XTiaj + XRia + XLia |S sybndp, Vv p, 
i Osd-pslagj J 


provided that the following constraint is also included, 


GUBia: )XTig Ss 1, Vid. 
y 


We now describe the implementation of the logical constraints 
mathematically. The first logical constraint is to ensure the total number of ship type i 
delivered in year dis € { 0, lwbndjq, ... , upbndjg }. The upper bound and lower 
bound are treated separately. 

a. Upper Bound Constraint 

Using the binary variables, the upper bound constraint is written 
simply as: 


UPPER jg: di XTigj + XRid +XLiq S upbndjg, Vid 
i 
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b. Lower Bound Constraint 

Ensuring that the number of type i ships delivered in year d is either 
zero or greater than or equal to the lower bound Iwbndjg is the most involved 
constraint in the model. This constraint needs to be stated explicitly only when 
lwbndjg 2 2. (It holds automatically when lwbndjg = 1, because the variables are 
integer.) 

The lower bound constraints involve only typical and resumption 
ships, because lead ships are always built in isolation. That is, if a leadship is built, 
the lower and upper bound on total ships of its type is one. 

The inequalities designed for handling the lower bound constraint are 
dependent on knowledge of the constraint’s limited scope and on simultaneous 


enforcement of other constraints. Assume for a specific i,d: 
1) lwbndjg 22 
2) DXTig <1 
J 


a) ALig=O or > XTidj + XRig =0 
J 
4) XTigj=0 forj € {lwbndjg-1, ... , upbndjg} 


The first assumption is made because otherwise the lower bound 
constraint under discussion is moot. The second assumption is justified by 
appealing to the GUB constraint. The third assumption appeals to the “leadship- 
first” constraint, and the fact that the optimizer will not choose to build a leadship 
twice, since they cost more. The fourth constraint is justified simply by model 


design: we define XTjqj to exist only for je {lwbndjg-1, ..., upbndjq}. 
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Under these assumptions, there are eight mutually exclusive and 
collectively exhaustive cases, which can be represented in a four-by-two table. The 
rows of Table 1 correspond to possible values for the number of typical ships 
delivered. The columns correspond to possible values for the resumption ships. 


The entries of the table indicate feasibility with respect to the lower bound constraint. 
TABLE 1. FEASIBILITY WITH RESPECT TO THE LOWER BOUND CONSTRAINT. 


Number of Resumption Ships 
Number of Typical Ships XRjg =0 XRig = 1 


i XTidqj = 0 Feasible Infeasible 
L 


i XTiaj = lwbndjg-1 Infeasible Feasible 
j 


Dy XTidj = lwbndid Feasible Feasible 
J 


> XTiaj > lwbndjq Feasible Feasible 
i 





Six of the eight cases are feasible and two are infeasible. A set of linear 


inequalities that correctly discriminates between the feasible and infeasible cases is: 
XTjdj $ XRiq for j=lwbndjg - 1 
XRig < yy XTidj 
J 


The first of these inequalities rules out the infeasible case represented in 


the second row, first column of Table 1. The second inequality rules out the other 


ee 


infeasible case. The feasible cases do not violate either condition. Based on this 


analysis, we include the following constraints in the implementation model: 


LOWERI]ig: = XTigj - XRid < 0, j= lwbndjg - 1, V td with lwbndjg 2 2 


LOWER2ja: XRid - 2XTiggS 0, Vid with lwbndjq 2 2 
j 


c. “Leadship-First” Constraints 

The next logical constraint to be developed is one that forces a leadship 
to be purchased before any typical (or resumption) ships of its type are bought. 
This constraint applies only to new ship types. A zero/one parameter gotsome; 
(derived from havejg and gettingjg) indicates whether any ships of type i are in 
existence or under construction. If gotsome; = 0, then a set of “leadship-first” 
constraints for ship type i must be added to the model. Without these constraints, 
the optimizer would tend to purchase typical ships without ever buying the more 
expensive leadships. 

Assuming binary values for the decision variables and satisfaction of 


the GUB constraints, the sum 
> XTiaj + XRid 
J 


will have value one or two if any non-leadships of type i are delivered in year d. 
Otherwise, this sum will be zero. 


For any given i,d, with gotsome; = 0, the sum 


YXLia’ 
d'<d 


will be one if a leadship of type i is delivered prior to year d. If no leadship exists in 


year d, this sum will be zero. 


3) 


The required constraint is to prevent a non-leadship from being 


delivered prior to a leadship delivery. This can be expressed as 


Si XTiaj + XRid <2 SY XLid’ 
j d'<d 


for allid with gotsome; = 0. In the elastic formulation, the constraint is: 


LEADFRSTig: >)XTigj+ XRid -2 Xia’ £ 0, Vid with gotsome; = 0 
) d'<d 


In some Navy planning, delivery of typical ships is not scheduled 
until two years after the leadship. This affords more time for test and evaluation of 
the leadship before opening a production line. The model can easily be modified to 


enforce this scheduling constraint by redefining the leadship-first constraint as 
>XTigi + XRig - 2. ))XLia’ S 0 
J d'<d-1 


d. Production Resumption Constraints 
The next logical constraint from the conceptual model to be formulated 
mathematically is the requirement to purchase a resumption ship after a production 
break. Typical ship delivery of type i is allowed in year d only if type i is delivered 


the previous year or a resumption ship is delivered the same year. That is 
DXTigj 21 
J 

is feasible only if 


XRid =1 or YXTig-1j + XRid-) + XLig-] 21 
Jj 


A constraint which enforces this relationship is: 


PRODBRKid: )XTidj- XRid - D(XTia-1j) - XRid-] -XLid-1 ¥ 0,Vid 
Jj J 


In order to help keep this constraint from forcing the solver to always 
lead off with a resumption unit, some early values of XTjg and XRjg are fixed using 
the value of gettingjg, if gettingjg = 1. Since new ships will require lag; years to 
construct, the first lagj years cannot have any new ships delivered that are not 
already in construction (and thus are included in gettingjqg). The actual method of 
fixing the decision variables is shown in the GAMS input file in the Appendix. 
Fixing the decision variables in this way also ensures that the calculated expenditures 
are correct, and allows the user to input the projected budget, not the projected 
budget less the amount required for ships already in construction. Additionally, if a 
leadship is being constructed the user will use a parameter leadshipjg, in the same 
way as gettingjg. This allows fixing the variable XLjq in the same matinee In order 
to improve solution times the planner may fix XLjg to one for some particular year d 
which is thought to be the year that the leadship will come on line. Then, by 
varying the fixed delivery year, several solutions may be obtained. 

e. Objective/Penalty Function 

The objective/penalty function is a function of all the elastic variables 
multiplied by their penalty. The penalty associated with a particular elastic variable 
should reflect the ship type and the year associated with the variable. If a constraint 
must be violated, the user would rather violate constraints associated with smaller 
ships than with very large and expensive ship. In addition, the user would rather 
violate constraints as far in the future as possible. With this in mind, the penalties are 
discounted for ship type and year. The method for discounting by ship type uses 
the concept that the larger ships are also more expensive. The penalty is multiplied 
by a ratio of the particular ship’s cost to the cost of the most expensive ship. For 


yearly discounting, the user inputs a value for the parameter discnt. The penalty 
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discount from one year to the next is (1 + discnt). If the user desires the penalties 
discounted by 5% per year, discnt will require a value of -0.05. If for some reason 
the user would rather the model violate constraints in the nearer years (if they must 
be violated) discnt will require a positive value. 

In order to allow the total penalty to be calculated, the penalty factors 
are scaled to ensure the same units are being added. For example, if the budget 
constraint is violated, the associated elastic variables need units of dollars (in order to 
add to or subtract from the budget for that year). But, the other elastic variables will 
be generally in units of ships. To keep the penalty units the same, the penalty factor 
associated with the elastic variable for budget violation is divided by the cost of the 
most expensive ship. This will yield a penalty for budget violation with units of 
penalty per ship. It should be noted that there is a negative penalty (or reward) for 
spending less than the budget. The reward for spending less than the budget by 
some amount is of course much smaller than the penalty for overspending the 
budget by the same amount. By using this reward system, if two sets of decision 
variables have the same penalty (other than the reward), the one which uses the least 
money has the lower overall penalty. 

A redundant constraint for XLjg similar to the GUB constraint for 
XTjqj is helpful in the integer enumeration. The following constraint ensures that the 


total number of leadships constructed for ship type i must be no more than one. 


MAXLEAD;: >XLig £ 1, Vi, with gotsome; =0 
d 


The elastic variables are Ul, Vl, Y2, Z2, E3, ... , E10, 


corresponding to the constraint number, with the penalties upen, vpen, ypen, zpen, 


pen3, ... , penl0. The implemented formulation (with constraint numbers 
reassigned) is: 
MIN: PENALTY 
ST: 1) » [ ) @XTiaj) + XRig’ + XLig’] = netdemig, Vid 
d’sd ‘j 
2) d, [ 2 GXTiaidp + XRigtidp + XLidclidp ] = budgety , Vp 
3) > [ d @XTig)+XRid +XLia] < sybndy, vp 


i Osd-pslagi j 
4) XC XTjdj) + XRid + XLid < upbndjg, Vid 
J 


5) XTidj -XRid < 0, j =lwbndjg - 1, V id with lwbndjg > 2 

6) Rig - 2xTig) § 0, V id with lwbndjg > 2 

7) Lorri) «xR wD) Poni) < 0, Vid with gotsome; = 0 
8) Yana. XRig - xT aie XR XL; gO, Vid 
9) bx <1, vid” 


10) Oy, < 1, Vi, with gotsome; =0 
d 


BENALTY = S(upenjgu1 id +vpenigV lig +pen4jgE4id +penSjgESig ) 
id 

+ > (pen6jdE6id +pen7jgdE7iqd +pen8jgE8 ig +pen9jgE9ig ) 
id 


+ >(pen10;E10;) + d(ypenpY 2p - ZpeNpZ2p + pen3pE3p ) 
l Pp 


D. OUTPUT 
The output from the model is displayed in three reports. An example of partial 


output reports is displayed below in Figure 1. 
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PARAMETER REPORT1 SHIPS BUILT VS. SHORTAGE OR EXCESS BY YEAR 

YEAR6 YEAR6 YEAR6 YEAR7 YEAR7T YEAR7 YEARS YEARS8 
BUILT SHORT EXCESS BUILT SHORT EXCESS BUILT SHORT 

TYPE1 1.00 

TYPE2 1.00 

TYPE3 1.00 

TYPEA : 

TYPES : . 4.00 : 2.00 

TYPES : c 1.00 

TYPE7 ‘ : 


PARAMETER REPORT2 EXPENDITURES VS. BUDGET BY YEAR 
YEAR3 YEAR4 YEARS YEAR6 
EXPENDED 4160.00 4243.00 4329.00 3605.00 
BUDGET 4160.00 4243.00 4327.00 4413.00 
OVERRUN 2.00 
SAVINGS 808.00 


PARAMETER REPORT3 CONSTRAINT ELASTICITY VARIABLES 
E3 ES E6 


TYPEI.YEAR9 

TYPE3.YEAR3 1.0 

TYPE4.YEAR1 1.0 
TYPES. YEARS 

TYPES. YEAR6 

TYPE6. YEAR9 





Figure 1. An example of partial output reports from the model. 


The first report, REPORT1, in Figure 1 provides the ship purchasing plan 
produced by the model. The columns named “BUILT” give the number of ships to 
be purchased for each ship type during a given year. The columns named 
“SHORT” and “EXCESS” give the number of ships which are short and in excess, 
respectively, of the required number of ships specified by the input data called 
needjd. With this report the user can either implement the ship purchasing plan 
under the column “BUILT” for each year and ship type. The more logical option is 
to use that plan as the starting point and consider the other columns (i.e., “SHORT” 
and “EXCESS”) in order to develop a long range plan that takes other factors not 
modeled into consideration. For example, if a class of ships is built and the last ship 
in the class is not built due to upper or lower bounds, then the user may want to 


order that particular ship with the last order for that ship type, or split the last order. 
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The idea is to use the model’s output as a tool for developing a long range plan, not 
to expect the model to produce the “optimal” plan. The second report shows the use 
of money and displays the budget, the amount expended, the amount of budget 
overrun, and the amount expended below the budget, for each year. The third 
report displays the values given to the constraint elasticity variables not shown in the 
first two reports for each time period and year. If the value of some constraint 
elasticity variable is not zero, then the solution displayed in the first two reports is 
actually not feasible, with respect to the constraint associated with that elasticity 
variable. Should the third report show anything other than “all zero”, the user 
should consider modifying the input values associated with elastic penalties, or 
bounds (upbndjg, lwbndjg, sybndg, and budgetp) and rerunning the model. The 
values to be modified will depend on which elastic variable had a value other than 
zero. Then, the user should report to their superiors that the stated desires are not 
feasible and provide them with values which are feasible. This information can also 
be used as a basis for negotiating new resources or mediating between conflicting 
desires. The later would normally entail performing sensitivity analysis of the 


penalties. 


E. LIMITATIONS 

In our implementation of the model, we have chosen to leave out several realistic 
features in order to make the model readily understandable. Although these features 
do represent limitations to the model, they can indeed be included at the expense of 
increased model and computational complexity. Below, we list these limitations. 

1) Except for the extra cost of a leadship or resumption ship, the model assumes 
the cost associated with a purchase is a linear function of the number of ships 


purchased. This does not allow quantity discounts, learning-curve effects, or 


1S 


economies of scale. This deficiency can be corrected, but additional user input and 
model complexity will be required. 

2) There is no lower bound on the total number of ships that can be under 
construction in a given year. 

3) There is no cost associated with shutting down a production line. The cost of 
the variable XRjq includes the cost of restarting a production line, but the cost of 
shutting down is considered negligible. Associated with this limitation is the 
assumption that the cost of restarting a production line is not a function of the 
number of years the production line has been secured. 

4) The model does not handle Ship Life Extension Program (SLEP) ships. To 
do so, constraints which force the solver to consider SLEP ships must be added to 
the model. 

5) The model shown in the Appendix has limits on the magnitude of set at five 
and the number of years over which payments may be made for any ship type to 


five years. 


20 


III. COMPUTATIONAL EXPERIENCE 


The model is written and tested using the General Algebraic Modeling System, 
GAMS [Ref. 6]. GAMS is essentially a model-solver interface. It allows the model 
constraints to be written in an index-exploiting, algebraic form similar to the 
mathematical form used in scientific communication. This makes it easy to translate 
the model from the mathematical form presented in the previous chapter to the 
computer input that can be used by the GAMS interface. GAMS then translates the 
model into a form required by the solver. The available solvers include ZOOM 
[Ref. 7] and MPSX [Ref. 8]; both of which are used in this research. According to 
Reference 9 [page 3], GAMS 


1. Provides a high-level language for the compact representation of large and 
complex models 


2. Allows changes to be made in model specifications simply and safely 
3. Allows unambiguous statements of algebraic relationships 
4, Permits model descriptions that are independent of solution algorithms 


Several small scale data sets were used to validate the formulation. Initially, the 
solution was not required to be integer, and the linear programming solver MINOS 
[Ref. 10] was used. As the model neared completion, a more realistic sized data set 
and the ZOOM mixed-integer programming solver were introduced to test the 
model’s ability to generate integer solutions. However, ZOOM “‘is intended for 
medium-sized problems with no special structure and up to about 200 zero/one 
variables.” [Ref. 9:p. 225] Since the actual data set requires about four times this 
many zero/one variables, ZOOM quickly became inadequate with the large model. 
So, for the purpose of comparing different solvers, an intermediate sized data set 


was used. This data set allows a maximum of five ships of any one type to be 


Z| 


constructed per year (/), considers ten ship types (i), and has a ten year planning 
horizon (da). The model was sent to Professor Terry Harrison at Pennsylvania State 
University through BITNET, an electronic mail network worldwide. At Penn 
State, the MPSX solver was used to solve the same data set. The results are 


summarized in Figure 2. 


Input data set has : Typical Model has: 


10 years (d and p ) 335 rows of equations 

10 ship types (i ) 990 columns of variables 

5 ships max per year of each type (/ ) 268 discrete variables 

4891 non-zero elements 
Computer Times: 
NPS IBM 3033AP: IBM 3090-400: 
GAMS: 28.630 sec GAMS: 9.020 sec 
Solver (ZOOM): Solver (MPSX): 
1000 iter’s 155.150 sec 10000 iter’s 67.800 sec 

50000 iter’s 1300.068 sec 

| : 18.9% Gap i ity: 14.6% Gap 





Figure 2. Computer time comparison for intermediate sized data set. 


The ZOOM solver has difficulty handling even this intermediate sized data set, 
showing no gain in solution quality from 1000 to 50000 iterations. MPSX, on the 
other hand, yields a better solution quality much faster and with fewer iterations. 
Several runs were made with the two solvers as the model continued to develop, 


with the same results. A larger, more realistic, data set was constructed and solved 


pas 


with ZOOM and MPSX (via Anthony Brooke), the results are summarized in 
Figure 3. Interestingly, on this larger problem, both solvers found a better quality 


solution. 


Input data set has : Typical Model has: 


15 years (d and p ) 1158 rows of equations 


20 ship types (i ) 2685 columns of variables 
5 ships max per year of each type (/ ) 742 discrete variables 
16688 non-zero elements 
Computer Times: 

NPS IBM 3033AP: IBM 3090-400: 
GAMS: 73.520 sec GAMS: 20.140 sec 
Solver (ZOOM): Solver (MPSX): 

30000 iter’s 1458.087 sec 24773 iter’s 644.400 sec 
Solution quality: 5.4% Gap Solution quality: 0.49% Gap 





Figure 3. Computer time comparison for realistic sized data set. 


In terms of solution quality, MPSX dominates ZOOM. However, ZOOM does 
give an integer solution, which is a far better starting point for developing the long 
range shipbuilding schedule than the typical “don’t build anything”’ starting point. 
Additionally, in ZOOM’s favor, a good solution is generally produced early on in 
the iteration count (e.g., From Figure 3, the same solution is given after 20000 
iterations as is given at 30000 iterations). However, it seems unable to search 
through this large a problem tree and find an improving solution. ZOOM will run 


on personal computers (taking much longer than the above times), so it can be used 


more easily with the model’s actual classified data. MPSX, on the other hand, 
generally provides a better solution in much less computer time, but requires a 
mainframe computer. 

Another solver option, which is currently being developed for use with 
GAMS, is the X-System [Ref. 4] which has solved similar problems of a much 
larger scale in relatively small computer times. Reference 11 develops a very similar 
model for Army helicopters with 4000 constraints, 21000 variables, 300 binary 
variables, and 100000 non-zero coefficients which is solved in about a minute when 
using the X-System (on an IBM 3033AP). 

The final option is to discard GAMS as a front end and write an independent 
solver specific to this model. This would indeed reduce the required computer time, 
but would do so at great development cost and at the expense of the GAMS 
flexibility and ease of use. Since the model will probably require solving many 
times with varied input data sets and several “what if” scenarios, and even with 
additional constraints, the GAMS front end is too valuable to discard. It is possible, 
of course, to write a front end to the model specific solver, which is as user friendly 
as GAMS. 

Of particular value throughout this research was the GAMS “dollar operator”. 
The dollar operator is “... used for exception handling in equations.” [Ref. 9:p. 92] 
“A dollar operator within an equation is an implied if-else operation ....” [Ref. 9: 
p. 94] The dollar operator proved essential in keeping the number of variables and 
constraints down to a manageable figure. For example, consider the large data set 
whose features are shown in Figure 3. Without the dollar operator to restrict the 
variables and constraints there are 2151 constraints, 4551 variables, 2100 of them 


discrete. This is twice as many constraints and twice as many variables, so the 
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problem size is four times what it is with the dollar operator. Obviously this feature 
of GAMS is essential to the model. 

A key element of the model is the penalty factors. Setting these penalties 
correctly is very important. In this study, the penalty factors were set iteratively by 
solving the linear programming relaxation of the model. This allowed the results to 
be returned quickly, and did not use up precious computer time. To start with, all 
penalty factors were set to one, and the general penalty factor for violating logical 
constraints (epen) set to ten. Then the individual factors were raised and the general 
penalty lowered to achieve the lowest penalty (with one being the lowest factor used) 
with a solution which did not violate the logical constraints. The ship balance 
constraint (DEMAND) was allowed to be violated, and the budget allowed to be 
under spent, but the other constraints were not allowed to be violated. Examining 
the marginal value of the elastic variables and constraints was also helpful. The 
adjustment of penalties continued until the linear program produced a near integer 
solution at which point the model was transferred to an integer program solver. 
Since the units are not the same for each constraint, the penalties were scaled so that 
approximately equivalent units are added in the penalty/objective function. This 
technique proved to be useful in producing integer solutions, and at setting the 


penalties. 
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IV. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

During the course of this study, GAMS has proven to be a valuable tool in the 
model development. GAMS is both user friendly and quite flexible. It is this 
flexibility feature that allows for “what if” type analysis. Moreover, one can also 
develop a “front end” program to interact with GAMS and thus further enhance the 
user friendliness of the overall model. 

As for the integer solvers, two solvers: MPSX and ZOOM were available 
during the study. Based on a realistically sized data set, MPSX clearly dominates 
ZOOM. However, ZOOM is available on a 386 based personal computer and 
MPSX is only available on large mainframe computers. Another solver, the X- 
System, was not interfaced with GAMS; however, based on reports of its 
performance on a similar problem, it could conceivably outperform both MPSX 
and ZOOM. 

In Chapter III, it is demonstrated that the model developed in this study does 
produce the desired result, i.e., an initial plan which analyst/planner can analyze and 
improve upon. It is cautioned that the model should not be treated as a “black-box” 
because solutions are “optimal” relative to the data provided by users. In planning, 
these data are generally rough estimates of actual values, hence the plans produced 
by the model should be treated at best as a guideline for producing a more sensible 


plan. 
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B. RECOMMENDATIONS FOR FURTHER IMPROVEMENT 
To further enhance the realism and perhaps the usefulness of the model, the 
following features can be included in the model. 
1. Incorporate Average Ship Age 
The helicopter model developed in Reference 11 incorporates average ship 
age. Not only are new helicopters brought on-line, but that model also determines 
the retiring times of the current stock of helicopters. 
2. Include Shutdown Costs 
This model, as presented, does not consider the cost of shutting down the 
production line, in order to keep the level of complexity compatible with available 
solvers. A new variable representing the cost of shutting down the production line 
can be introduced. 
3. Use Economies of Scale in Production Costs 
As pointed out in the model assumptions, economies of scale when 
purchasing ships is not allowed. Cost in this model is a linear function of the 
number of ships purchased of a given type. Since economies of scale exist, their 
introduction into the cost function could enhance the model. 
4. Develop a User-Friendly Front End for the X-System 
As stated earlier, the X-System is an alternative solver which is not yet 
available with GAMS. By developing a front end to the X-System, one would be 
able to evaluate the advantages of the X-System over the other solvers. 
5. Provide Graphical Displays of Solutions 
Although displaying solutions to the model numerically is adequate for 


current usage, a graphical display is more preferable to the user. 
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APPENDIX : GAMS INPUT FILE 


SOFFUPPER OFFSYMLIST OFFUELLIST OFFUELXREF OFFSYMXREF 
* Long-Range Shipbuilding Scheduling Model 


* By LT Joe Faircloth, USN, 8 August 89 (userid 1651p) 

* Based on model by Prof. Richard E. Rosenthal, 6 Sep 88 
OPTION LIMROW = 0, LIMCOL = 0, SOLPRINT = OFF; 

OPTION ITERLIM = 30000, WORK= 15000, RESLIM = 5000; 
OPTION OPTCR = 0.00, OPTCA = 1.0; 


Kak KKK KKK KKK RKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK 


xxx The next area contains data which must be filled KKK 
*x* in by the user, or a call to a data file with it. *** 


xxx The following items must be filled included: ns 
Ese tal Seaess LU, IW witafies 
Beats Tables: HAVE, GETTING, LEADSHIP, NEED, Uses 
Bees ES COST1, COST2, COST3, UPBND, LWBND Uses 
2 SAIES Scalars: INITBUD, GROWTH, UFAC, VFAC, YFAC Beate 
hated DISCNT, EPEN, P3, P4, P5, P6, eliahel 
ela P7, P8, P9, P10 lala 
xxx Parameters: UPBOUND Bethe 


Keke KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK 


*SINCLUDE GAMS DATASET A 
* NOTE this dataset covers only 5 years, 5 ship types, max of 5 ships 
* delivered per year. This dataset is for demonstration purposes only. 


Seas 
I ship types / TYPE1, TYPE2, TYPE3, TYPE4, TYPES / 
D delivery years / YEAR1 * YEARS / 


J amount of typical units to buy 1*oe, 
TIME time relative to year of delivery used for cost input only 
/ YR-MINUS-0, YR-MINUS-1, YR-MINUS-2, YR-MINUS-3, YR-MINUS-4 /; 


TABLE HAVE(I,D) number of each type we have from current inventory 


YEAR1 YEAR2 YEAR3 YEAR4 YEAR5 

TYPE1 3 3 3 z 1 

TYPE2 2 2 2 1 1 

TYPE3 4 4 4 4 3 

TYPE4 4 4 3 3 3 

TYPE5 0 0 0 0 0 

TABLE GETTING(I,D) units coming online that are in construction now 

a will come online after yearO but before lag(i)+yearl 
YEAR1 YEAR2 YEAR3 YEAR4 YEARS5 

TYPE1 1. 2) 

TYPEZ2 3} 

MOS EITS) al 
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TABLE LEADSHIP(I,D) leadships coming on line that have been started 


0 before yearl and will come on line after year0 
YEAR1 YEAR2 YEAR3 YEAR4 YEARS 
TYPES 1 
TABLE NEED (I,D) number of each type we want in each year 
YEARI1 YEAR2 YEAR3 YEAR4 YEARS 

TYPE 6 6 6 6 6 
TYPE2 5 5 5 5 3 
Mee S 8 8 8 8 8 
TYPE4 © S S 9 g 
TYPES 0 0 0 1 1 
TABLE COST1 (1, TIME) typical ship cost data in appropriate year 
se relative to the delivery year 

YR-MINUS-0 YR-MINUS-1 YR-MINUS-2 YR-MINUS-3 YR-MINUS-4 
TYPE1 10 100 
TYPE2 20 200 
TYPES 30 300 
TYPE4 40 100 400 
TYEES 50 500 
TABLE COST2 (I, TIME) cost data for first unit after production break 
is including cost of restarting production line and 
ws the cost of the typical unit 

YR-MINUS-0 YR-MINUS-1 YR-MINUS-2 YR-MINUS-3 YR-MINUS-4 
ive ed 10 110 
TYPE2 20 220 
WEISS) 30 330 
TYPE4 40 150 400 
TYPES 50 550 
TABLE COST3 (1, TIME) leadship cost data 

YR-MINUS-0 YR-MINUS-1 YR-MINUS-2 YR-MINUS-3 YR-MINUS-4 
WIGLIsS) 100 800 
TABLE UPBND (1,D) upper bound on the number of each type produced 
* per year if any are to be produced 

YEAR] * YEARI5 
savas Ele Z 
TYPE2 S) 
GS Gea; 8} iL 
TYPE4 4 
FIBA ET 2 
TABLE LWBND (1,D) lower bound on the number of each type produced 
* per year IF ANY are to be produced 
YEAR1 * YEAR15 

sport IL 2 
WOE 2 3 
Rye ES alt 
Boa 2! 3] 
TEES 1 
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PARAMETER UPBOUND(D) upper bound on the total ships under construction; 
* 


in year d 
UPBOUND (D) = 10; 
SCALARS INITBUD first year budget / 2000/ 
GROWTH budget growth rate as percent / O2027e; 

* Set penalty factors for constraint violations 

SCALARS 
DISCNT time weighting factor for penalties 7-0 .057 
UFAC ship shortage factor per ship f2/ 
VFAC ship excess factor per ship [2/ 
YFAC budget overrun factor per cost of largest ship fel aly2 
EPEN general constraint violation penalty /10/ 
PS penalty for violating overall construction bound /1/ 
P4 penalty for violating upper bound per ship Hd 
P5 penalty for violating lower bound /1/ 
P6 penalty for making only one ship if LT lwbnd /1/ 
P7 penalty for not producing leadship first ily 
P8 penalty for not making a resumption unit if reqd /2/ 
P9 penalty for violating GUB bound on XT fay 
P10 penalty for violating GUB bound on XL /1/; 


Kam RAK KK KKK KK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK 


xxx End of area containing data which must be filled *** 
xxx in by the user. The next area has aborts to Babette 


*x* ensure the data has been entered correctly. Esthet 
Kae ka K KK RAK KKK KKK RAK KKK KKK KKK KKK KKK KKK KKK KKK 


ABORT $(SUM((I,D)$(HAVE(I,D) LT 0),1) GT 0) 
"xx*=>Data entry error in table HAVE, entries may not be negative", 
HAVE; 


ABORT $(SUM((I,D)$(GETTING(I,D) LT 0),1) GT Q) 
"xx*=>Data entry error in table GETTING, entries may not be negative", 
GETTING; 


ABORTS (SUM((I,D)$((LEADSHIP(I,D) LT 0) OR (LEADSHIP(I,D) GT 1)),1) GT 0) 
"x*xekx=>Data entry error in table LEADSHIP, entries may only be zero or 
one", 

LEADSHIP; 


ABORT $(SUM((I,D)$(NEED(I,D) LT 0),1) GT Q) 
"x**=>Data entry error in table NEED, entries may not be negative", 
NEED; 


ABORT $(SUM((I,D)S(NEED(I,D) LT (HAVE(I,D)+GETTING(I,D))),1) EQ CARD (I) 
*CARD(D)) "***=>NEED is satisfied by HAVE+GETTING, for every I,D", 
Mi There is no need to run the program, it is already optimal", 
HAVE, GETTING, NEED; 


ABORT $(SUM( (I, TIME) $(COST1(I,TIME) LT 0),1) GT 0) 


"*x*k*=>Data entry error in table COST1, all costs must be non-negative", 
GOST; 
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ABORT $ (SUM( (I, TIME)$(COST2(I, TIME) LT 0),1) GT 0) 
"x*x*x=>Data entry error in table COST2, all costs must be non-negative", 
COST. 


ABORT $ (SUM((I,TIME)$(COST3(I,TIME) LT 0),1) GT 0) 
"x**x=>Data entry error in table COST3, all costs must be non-negative", 
COSiTs); 


ABORT $(SUM((I,D)S(UPBND(I,D) LT 0),1) GT 0) 
"*x*=>Data entry error in table UPBND, entries may not be negative", 
UPBND; 


ABORT $(SUM((I,D)$(LWBND(I,D) LT 0),1) GT 0) 
"*x*x*=>Data entry error in table LWBND, entries may not be negative", 
LWBND; 


ABORT $(SUM((I,D)$(UPBND(I,D) LT LWBND(I,D)),1) GT 0) 
"*x*=>Data entry error in table LWBND or UPBND, LWBND must be less", 
" than or equal to UPBND, for all i,d.",LWBND, UPBND; 


ABORT S(INITBUD LE 0) 
"*x*=>Data entry error for INITBUD, entry must be positive", 
INITBUD; 


ABORT $((UFAC LT 0) OR (VFAC LT 0) OR (YFAC LT 0)) 

"xxkx=>Data entry error in UFAC,VFAC,or YFAC, values may not be 
negative", 

UFAC, VFAC, YFAC; 


ABORT $((UFAC + VFAC + YFAC) EQ 0) 
"***=>A1]1 penalties are zero, program is optimal as is.", 
M UFAC, VFAC, and YFAC must not all be zero.", UFAC,VFAC, YFAC; 


KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK 


EIS End of ABORTS checking user data input. EF esiaS 
Easites The next areacalculates additional data Lert 
sis not required to be input by the user. Lats 
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* D is used for year of delivery and P is used for year of payment 
ALIAS (D,P); 


PARAMETER CT (I,D,P), CR(I,D,P), CL(I,D,P): 

CT(I,D,P)$(ORD(D) - ORD(P) EQ 0) = COST1(I,"yr-minus-0"); 
CT(I,D,P)$(ORD(D) - ORD(P) EQ 1) = COST1(I,"yr-minus-1"); 
CT(I,D,P)$(ORD(D) - ORD(P) EQ 2) = COST1(I, "yr-minus-2") ; 
CT(I,D,P)$(ORD(D) - ORD(P) EQ 3) = COST1(I,"yx-minus-3"); 
CT(I,D,P)$(ORD(D) - ORD(P) EQ 4) = COSTI(I,"yr-minus-4"); 


CR(I,D,P)$(ORD(D) - ORD(P) EQ 0) 
CR(I,D,P)$(ORD(D) - ORD(P) EQ 1) 
CRG, D, EP) > (ORD) — ORD(P) EO 2) 
CR(I,D,P)$(ORD(D) - ORD(P) EQ 3) 
CRG De) o(ORD(D) ORD) (Ey) ON) 


COS TATCe aL yen Onn iy 
COSTAIGG Ay e—mamus san) y; 
COST2 (I, "yr-minus-2") ; 
COSTA aay soon su je, 
COST2 (I, "yr-minus-4") ; 


sll 


CL(I,D,P)$(ORD(D) - ORD(P) EO 0) 
CL(I,D,P)$(ORD(D) ~- ORD(P) EQ 1) 
CL(I,D,P)$(ORD(D) ~ ORD(P) EQ 2) 
CL(I,D,P)$(ORD(D) - ORD(P) EQ 3) 
CL(I,D,P)$(ORD(D) - ORD(P) EQ 4) 


COSEs(h, yr-mi nus—Onn 
COST3 (I, "yr-minus-1"); 
COST3(I,"yr-minus-2") ; 
COST3 (I, "yr-minus~-3"); 
COST3 (I, "yr-minus-4") ; 


PARAMETER LAG (I); 

LAG (I) $ (COST1 (I, "yr-minus-4") GT 0) = 4; 

LAG (I) $ (COST1 (I, "yr-minus-3") GT 0 AND LAG(I) EQ 0) 
LAG (1) $ (COST1 (I, "yr~minus-2") GT 0 AND LAG(I) EQ 0) 
LAG (I) $(COST1 (I, "yr-minus-1") GT 0 AND LAG(I) EQ 0) 
LAG (I) $ (COST1 (I, "yr-minus-0") GT 0 AND LAG(I) EQ 0) 


— 


° 
’ 

° 
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PARAMETER BUDGET(P) money available in year P to purchase ships; 
BUDGET (P)$(ORD(P) EQ 1) = INITBUD; 
LOOP (P,BUDGET(P+1) = FLOOR((1+GROWTH) *BUDGET (P))); 


PARAMETER DISCOUNT(D) discount factor for time weighting penalties; 
DISCOUNT(D) = POWER(1+DISCNT,ORD(D)-1); 


Calculate the penalty values for each unit of excess, shortage, 
and budget overrun for each type and year. Calculate all elastic 
constraint penalties. All penalties are discounted by year and 
relative to ship type cost. 

so that the right hand sides of the dual equations will be integers. 
PARAMETERS 

BIGC, PRIORITY (I) ,UPEN(I,D),VPEN(I,D),YPEN(D) ,ZPEN(D) ,PEN3(D), 

PEN4 (I,D) ,PEN5 (I,D),PEN6(I,D),PEN7 (I,D) ,PEN8(1I,D) , PENS (I,D) , PEN10 (I); 
BIGC = SMAX (I, SUM(TIME, COST1 (I, TIME) )); 


+ + F F 


PRIORITY (I) = SUM(TIME,COST1(I,TIME)) / BIGC; 
UPEN(I,D) = UFAC * DISCOUNT(D) * PRIORITY (I); 
VPEN(I,D) = VFAC * DISCOUNT(D) * PRIORITY (I); 
YPEN (D) = YFAC * DISCOUMNPID I ElGe- 

ZPEN (D) = YPEN(D)/10; 

PEN3 (D) = EPEN*P3*DISCOUNT (D) ; 

PEN4(I,D) = EPEN*P4*DISCOUNT (D) *PRIORITY (I); 
PEN5(1I,D) = EPEN*P5*DISCOUNT (D) *PRIORITY (I); 
PEN6(I,D) = EPEN*P6*DISCOUNT (D) *PRIORITY (I); 
PEN7(I,D) = EPEN*P7*DISCOUNT (D) *PRIORITY (I); 
PEN8(I,D) = EPEN*P8*DISCOUNT (D) *PRIORITY (I); 
PEN9(I,D) = EPEN*P9*DISCOUNT (D) *PRIORITY (I); 
PEN10 (I) = EPEN*P10*PRIORITY (I); 


PARAMETER GOTSOME (I) equals 1 if you do not need to make a lead ship; 
GOTSOME (I) = 0 + 15S (SUM(D, HAVE (I,D)+GETTING (I,D)+LEADSHIP(I,D)) GT 0); 


PARAMETER NETDEM(I,D) totl number of i ships that must be del'd by yr d; 
NETDEM(I,D) = NEED(I,D) - HAVE(I,D); 


KKK RK KKK KKK KKK KKK KK KKK RK K KKK KKK KKK KKK KKK KKK 


ak All data is now calculated. The next area a 


mes ad es defines the variables and the constraints. Peat 
KKK Ra kw IK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK 
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VARIABLES 
xT(I,D,J) order j of type i to be delivered in year d 


XR(I,D) first one after a break in production costs more 
XL(I,D) first one of type i to come on line costs more 
sl (Ge) shortage of type i in year d 

RVeIe (Glee) excess of type i in year d 

Y2 (P) amount expenditure is over budget in year p 

Z2 (P) amount expenditure is under budget in year p 
E3(D) elasticity variable for equation construct 
E4(1,D) elasticity variable for equation upper 

E5(1,D) elasticity variable for equation lowerl 


E6(1,D) elasticity variable for equation lower2 
Es i(le, sD) elasticity variable for equation leadfrst 
E8(1,D) elasticity variable for equation prodbrk 
E9(1,D) elasticity variable for equation gub 

E10 (I) elasticity variable for equation maxlead 
PENTOT total penalties; 


BINARY VARIABLES XT,XR, XL} 

POSITIVE VARIABLES  U1,V1,Y2,22,E3,E4,E5,E6,E7,E8,E9, E10; 

*set x variables to getting(i,t) for those that occur prior to 
*yearl+lag(i). This may prevent making a prod break type when not needed 


*and will allow the correct budget amount to be used. 
XT.FX(I,D,J)$(( (GETTING (I,D-1) GE 1) OR (LEADSHIP(I,D-1) EQ 1)) 


AND (ORD(J) EQ GETTING(I,D))) = 1; 
XR.FX(I,D)$(( (GETTING (I,D-1) EQ 0) AND (LEADSHIP(I,D-1) EQ 0)) 
AND (GETTING(I,D) GE 1)) = 1; 


XT.FX(I,D,J)$(((GETTING(I,D-1) EQ 0) AND (LEADSHIP(I,D-1) EQ 0)) 
AND ((GETTING(I,D) GE 2) AND (ORD(J) EQ GETTING(I,D) - 1))) =1; 
XL.FX(I,D)$(LEADSHIP(I,D) EQ 1) = 1; 


KaK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK 


Sats Define dynamic sets of variables for use iS cPos 


Sot with dollar operators in the constraints eats 
KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK 


Cen ech), POS2(J,1,D), POS3S({1), POS4(1,D), POSS(Z,D,J), POS6(D,P), 
POs7(i, 0), ECS8(1,D,P), POS9(1,B), POSI0(1,D), POS11(1,D,P), 
ROSA (1, D-aN yp IWOSS (AC, 1D), IOs ildl (ie, 10))) 5 IXOSLS) (Cay, a0, 1B)) & 


© Sie (a,b) =YESS$ (ORD (D) GT LAG(I)); 
POS2(J,1I,D) =YES$((ORD(J) GE LWBND(I,D)-1) AND (ORD(J) LE UPBND(I,D))); 
POS3 (I) =YESS (GOTSOME (I) EQ 0); 
POS4 (I,D) =YESS ( (GOTSOME(I) EQ 0) AND (ORD(D) GT LAG(I))); 
POS5(I,D,J) =YESS(ORD(J) EQ LWBND(I,D)-1); 
POS6 (D, P) =YESS(ORD(P) LE ORD(D)); 
POS7 (I,D) =YES$((ORD(D) GT LAG(I)) AND (LWBND(I,D) GE 2)); 
POS8(I,D,P) =YES$((ORD(P) LT ORD(D)) AND (ORD(P) GT LAG(I))); 
POS9(I,D) =YESS((ORD(D) GT LAG(I)) OR (GETTING(I,D) GT 0)); 

) 


POS10(I,D) =YESS$(((GOTSOME(I) EQ 0) AND (ORD(D) GT LAG(TI)) 
OR (LEADSHIP(I,D) EQ 1)); 

POS11(1I,D,P)=YESS ((ORD(D)-ORD(P) GE 0) AND (ORD(D)-ORD(P) LE LAG(TI)) 
AND ((GETTING(I,D) GT 0) OR (ORD(D) GT LAG(I))))-; 
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POS12 (1,D, J) =YES$ (((ORD(J) GE LWBND(I,D)-1) AND (ORD(J) LE UPBND(I,D))) 
AND ((ORD(D) GT LAG(I)) OR (GETTING(I,D) GT 0))); 
POS13(I,D) =YESS$((ORD(D)-1 GT LAG(I)) OR (GETTING(I,D-1) GT 0)); 
POS14(I,D) =YESS(((GOTSOME(I) EQ 0) AND (ORD(D)-1 GT LAG(I))) 
OR (LEADSHIP(I,D-1) EQ 1)); 
POS15 (J,1,D)=YES$ (((ORD(J) GE LWBND(I,D)-1) AND (ORD(J) LE UPBND(I,D))) 
AND ((ORD(D)-1 GT LAG(I)) OR (GETTING(I,D-1) GT 0))); 


KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK 


viii Begin listing the constraints weit 
KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK 


EQUATIONS 
DEMAND (I,D) maintain inventory balance 
FISCAL (P) observe budget limits 


CONSTRUCT (D) prevents making more than the ship yard can make 

UPPER (I,D) total type i made in period t is less than max 

LOWER1 (I,D) with next eqn prevents making less than lwbnd(i t) 
LOWER2(I,D) with previous eqn prevents making less than lwbnd(i t) 
LEADFRST(I,D) ensures you make a first one before others if needed 
PRODBRK(I,D) ensures next type i after a prod break is prod break type 


GUB (1, D) ensures only one of the x binary types is made GUB 
MAXLEAD (T) gub bound on lead ships 
OBJDEF; 


DEMAND (I,D) $POS1(I,D) .. 
SUM (PSPOS6 (D,P) , SUM(JSPOS12 (I,P,J), 
ORD (J) *XT(I,P,J)) 
+ XL(I,P) $P0S10(I,P) 
+ XR(I,P) $POS9(I,P)) 
=E= NETDEM(I,D) - U1(I,D) + V1(I,D); 


FISCAL(P) .. 

SUM((I,D), SUM(J$POS12(I,D,J), 
XT(E,D,J)*ORD (a) ) *cCr( 1 bee) 
+XL (I,D) $POS10 (I, D) *CL(I,D, P) 
+XR(I,D) SPOS9 (I,D) *CR(I,D,P) ) 

=E= BUDGET(P) + Y2(P) - 22(P); 


CONSTRUCT (P) .. 
SUM(I, SUM(DSPOS11(1I,D,P), 
SUM(JSPOS2 (J,1I,D), ORD(J)*XT(I,D,J)) 
+ XR(I,D) + XL(I,D)S$POS10(I,D))) =L= UPBOUND(P) + E3(P); 


UPPER (I,D) $POS1 (I,D) 
SUM(JSPOS2(J,1I,D), XT(I,D,d)*ORD(J)) + XR(I,D) 
+ XL(I,D)$PO0S10(I,D) =L= UPBND(I,D) + E4(I,D); 


LOWER (I, D) $POS7 (I,D) 
SUM (JSPOS5(I,D,J),XT(I,D,J)) - XR(I,D) =L= 0 + E5(I,D); 


LOWER2 (I,D)SPOS7(I,D) .. 
XR(I,D) - SUM(JSPOS2(J,1I,D), XT(I,D,J)) =L= 0 + E6(I,D); 
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LEADFRST(I,D)$POS4(I,D) .. 
SUM(dsPOS2(J,1,D), XT(I,D,J)) + XR(T,D) 
= oUM(PlPOss (I,D,P), XL{I,P)*2) 
=L= 0 + E7(I,D); 


PRODBRK (I, D) $POS1 (I,D) 
SUM(JSPOS2(J,1I,D), 
XT(I,D,J)) - XR(I,D) - XR(I,D-1) $POS13(1,D) 
- XL(I,D-1) $P0S14(I,D) 
- SUM(J$P0S15(J,I,D), XT(I,D-1,J)) =L= 0 + E&8(I,D); 


GUB (I,D) $POS1 (I, D) 
SUM(J$POS2(J,1I,D), XT(I,D,J)) =L= 1 + E9(I,D); 


MAXLEAD (I) $POS3(I) .. 
SUM(D$POS1(I,D), XL(I,D)) =L= 1 + E10(I); 


OBUDERT =. 

SUM{(E,D)>POSI({I,D), UPEN(1,D)*U1({1,D) + VPEN(1I,D)*V1(1I,D)) 
SUM(P, YPEN(P)*Y2(P) - ZPEN(P)*Z2(P)) + SUM(D, PEN3(D)*E3(D)) 
SUM((I,D)$POS1(I,D), XRPEN*XR(I,D) + E4(I,D)*PEN4(I,D) 
Po(1,D)*PENS(1,D) + EG(1,D)*PEN6(I,D) + E9(I,D)*PEN9(I,D) 
E7(1I,D)*PEN7(I,D) + E8(I,D)*PEN8(I,D) ) 

SUM (I$P0S3(I) ,E10(I)*PEN10(I)) =E= PENTOT; 


t++eeet 
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*** All variables and constraints are now defined. Next *** 
*** send the model to the solver, then display the To tartas 


**x* solution from the solver. KKK 
KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KEK 


MODEL SHIPS /ALL/; 
SOLVE SHIPS USING MIP MINIMIZING PENTOT; 


PARAMETER REPORT1(I,D,*) ships built vs. shortage or excess by year; 
REPORT1 (I,D,"BUILT") =SUM(J,XT.L(I,D,J)*ORD(J)) +XR.L(I,D) +XL.L(1I,D); 
REPORT1 (I,D,"SHORT") = U1.L(I,D); 

REP ORs Ge Dy uExXCES Su)i—s Vale. (ls, D) i. 

OPTION REPORT1:2:1:2; 

DISPLAY REPORT1; 


PARAMETER REPORT2(*,P) expenditures vs. budget by year; 
REPORT2 ("EXPENDED", P) BUDGET (P) - Z2(P) + Y2(P); 


REPORT2 ("BUDGET", P) = BUDGET (P); 
REPORT2 ("OVERRUN",P) = Y2.L(P)?; 
REPORT2 ("SAVINGS",P) = Z2.L(P); 


OPTION REPORT2:2; 
DISPLAY REPORT2; 
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PARAMETER REPORT3 constraint elasticity variables; 
REPORT3 (I,D,"E3")$(ORD(I) EQ 1) = E3.L(D); 


REPORT3(I,D,"E4") = E4.L(I,D); 
REPORT3(I,D,"E5") = E5.L(I,D); 
REPORT3(I,D,"E6") = E6.L(I,D); 
REPORT3(I,D,"E7") = E7.L(I,D); 
REPORT3(I,D,"E8") = E8.L(I,D); 


REPORT3 (I,D, "E9") Eo 1 (hb; 
REPORTS (1,D,"B10") S(ORD(D)) EO) eer loan): 


OPTION REPORT3:1:2:1; 
DISPLAY REPORT3; 
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